前一篇處理「Taints／Tolerations：別讓一般 Pod 把 GPU 節點吃掉」，這篇進一步討論「Priority 與 Preemption：當 GPU 不夠時誰先活」。共同的量測條件是前後比較的基礎。

今天要回答的問題

設計互動推論、Embedding batch、ASR batch 三種優先級，觀察搶占與使用者體感。

工程邊界

稀缺 GPU 要有「誰可以上來」與「誰先活」兩層政策

Taint/Toleration 可以防止一般 workload 誤上 GPU Node，但這項設定不保證 Pod 一定會被排到 GPU Node；仍需搭配 resource request 或 affinity。PriorityClass 則是在資源不足時表達相對重要性，必要時可能觸發 preemption。

在 AI 平台裡可把互動式線上服務與可延後的 batch job 分層。重點不是讓高優先服務永遠搶資源，而是明確定義在壓力下的降級策略。

一個可以直接重現的起點

用 PriorityClass 表達服務重要性

互動式推論通常比離線 embedding batch 更在乎等待時間，因此可以把服務重要性明確寫入 PriorityClass。但搶占不是免費的：被終止的 batch 可能浪費已計算的工作，所以應同時記錄使用者體感與被搶占工作量。

把服務優先級寫進 PriorityClass

這份 YAML 將「建立兩種 PriorityClass，在單 GPU 壓力下觀察排程與 preemption」的變因與觀察欄位留在版本控制中，再由實際 workload 引用。

apiVersion: v1
kind: ConfigMap
metadata:
  name: day08-experiment
  namespace: ai-lab
data:
  change: "建立兩種 PriorityClass，在單 GPU 壓力下觀察排程與 preemption"
  fixed: "image, model, input"
  metrics: "Pending, preemption events, victim, ready time"
  repeats: "3"

驗證與落地方式

驗證可從「建立兩種 PriorityClass，在單 GPU 壓力下觀察排程與 preemption」開始。除了保存 manifest 的期望狀態，也要同步觀察 scheduler event、Pod 狀態轉換、node／GPU 資源與實際請求結果。Kubernetes 顯示 Running 只代表容器已啟動，不代表模型已載入、服務已 Ready，更不代表使用者請求符合 SLO。

這篇優先比較：Pending、preemption events、victim、ready time。測試時應準備一組不套用目標策略的對照組，再以相同 workload 套用新策略。若 placement 改善但等待時間、重啟次數或服務錯誤增加，代表問題只是從排程層移到執行層，不能直接判定方案有效。

常見誤判

• 只看 kubectl get pods 的最終狀態，忽略 Pending reason、event 順序與 readiness 變化。
• 把 GPU allocation 當成 GPU 效率；資源已分配仍可能因 queue、I/O 或模型載入而閒置。
• 只測單一 Pod，沒有涵蓋更新、驅逐、節點失效與重新排程，無法得知真正的服務中斷時間。

上線前檢查

部署前應確認 request／limit、affinity、taint、priority、probe 與 disruption policy 是否互相一致。變更後除了檢查 rollout，也要送出代表性請求，核對服務延遲、錯誤率與 GPU 指標。回滾條件需先定義，避免故障發生後才臨時決定是否撤回。若策略依賴特定 GPU 型號或叢集功能，也要明列適用條件，避免在不同 node pool 套用後得到相反結果。

如何閱讀結果

排程結果要和服務結果放在同一條時間線：先看 Pod 為何被放到某個節點，再看模型何時 Ready，最後核對請求是否成功。只改善 placement 卻讓 cold start 或資料下載變慢，仍然可能造成更長的使用者等待時間。

策略通過單次測試後，還要在 rollout、drain 與節點重新加入時重跑。這些事件會重新觸發排程與模型載入，最容易暴露 topology、storage、probe 與 disruption policy 之間的衝突。

結果判讀

判讀不只看最大或最漂亮的數字。這一天真正要回答的是：確認優先權規則符合服務等級且不造成無限飢餓。

如果核心指標改善，但錯誤率、尾端延遲、資源成本或恢復能力變差，這代表取捨，而不是無條件進步。相反地，沒有改善也不是無效結果；至少能排除一條看似合理、實際上不值得增加複雜度的路。

今天的結論

今天的工程判斷是：確認優先權規則符合服務等級且不造成無限飢餓。無論結果支持或否定原本假設，都必須保留完整條件，才能和下一天的實驗串在一起。

下一篇將處理：Namespace、Quota 與多團隊治理。

參考資料

• Kubernetes: Schedule GPUs
• Kubernetes: Resource Management
• Kubernetes: Assigning Pods to Nodes
• NVIDIA DCGM Documentation